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Objectives: To develop effective ways of sharing patients' medical information, we developed a new medical information ex- 
change system (MIES) based on a registry server, which enabled us to exchange different types of data generated by various 
systems. Methods: To assure that patient's medical information can be effectively exchanged under different system envi- 
ronments, we adopted the standardized data transfer methods and terminologies suggested by the Center for Interoperable 
Electronic Healthcare Record (CIEHR) of Korea in order to guarantee interoperability. Regarding information security, MIES 
followed the security guidelines suggested by the CIEHR of Korea. This study aimed to develop essential security systems for 
the implementation of online services, such as encryption of communication, server security, database security, protection 
against hacking, contents, and network security. Results: The registry server managed information exchange as well as the 
registration information of the clinical document architecture (CDA) documents, and the CDA Transfer Server was used to 
locate and transmit the proper CDA document from the relevant repository. The CDA viewer showed the CDA documents 
via connection with the information systems of related hospitals. Conclusions: This research chooses transfer items and de- 
fines document standards that follow CDA standards, such that exchange of CDA documents between different systems be- 
came possible through ebXML. The proposed MIES was designed as an independent central registry server model in order to 
guarantee the essential security of patients' medical information. 
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I. Introduction 

Since now, when a patient is transferred to another hospital, 
the patient needs to bring his/her own records and submits 
to the newly assigned doctors [1]. To lessen this inconve- 
nience, data transferring, or data exchanging techniques 
have been developed. The biggest limitation on this issue 
is that the records are in various forms by each doctor or 
each institution. To overcome this barrier, some web-based 
information sharing systems have been developed in some 
General Hospitals to communicate with their affiliated clin- 
ics to eliminate manual procedures recently. However, these 
kind of systems are not proper for the nation-wide standard 
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model but for their affiliated medical facilities [2] . The elec- 
tronic healthcare record (EHR) is an information system 
that integrates electronic medical record (EMR) maintained 
by individual hospitals to effectively exchange histories of 
patient's treatment record scattered around medical facilities 
[3]. 

In terms of improved medical service quality, better acces- 
sibility and enhanced safety for patients, EHR provides vari- 
ous benefits. Based on the electronic treatment information 
and clinical decision support system, EHR can check drug 
interactions to reduce prescription errors and constantly 
monitor pharmaceutical side-effects of safe medical services. 
Moreover, by making individual treatment information 
available regardless of time and location, EHR can increase 
patient's right to know, improve the ability to manage dis- 
eases, and alleviate the asymmetry between the medical staff 
and the patient [3]. EHR can also intensify personal infor- 
mation protection by implementing managerial, technical 
and physical measures against misuse and abuse of patient's 
treatment information [4] . 

The primary aim of this research was to build a medical 
information exchange system (MIES) which made it possible 
to exchange medical information between various medical 
information systems of hospitals and also guarantees the 
interoperability between medical information systems of the 
participating institutions. 

II. Methods 

To enhance the reliability and effectiveness of the medical 
information exchange between different medical institu- 
tions, the following factors is considered importantly: well 
screened items, data transmission methods, standardized 
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terminologies and security of data and system. 

Considering the above issues, this study adopted ebXML 
as data transmission standard suggested by Center for In- 
teroperable Electronic Healthcare Record (CIEHR) of Korea 
in order to transmit messages between various systems. 
Furthermore, in this study, the Web Service technique was 
adopted to connect EMR systems of each hospital. In addi- 
tion, the international standard of the clinical document ar- 
chitecture (CDA) R2 was used to enable nationwide transfer 
of medical records for the information exchange. We imple- 
mented the centralized EHR Registry Server which contains 
information to share. As a result, it enabled users to retrieve 
and distribute the CDA document from CDA Repository by 
patient's index. 

The EHR Registry Server is the center to store and manage 
information on hospitals, patient's medical information and 
their consent to release of their medical records. 

1. System Process and Architecture 

The MIES developed through this study have been tested by 
Seoul National University Bundang Hospital (SNUBH) as a 
general hospital and 33 nearby physician's clinics. Figure 1 
shows the delivery process model of referral from a physi- 
cian's clinic to a general hospital. The physician's clinic sends 
a referral message to the Registry Server when referring the 
patient and it will store the CDA document at its CDA Re- 
pository. Then it sends referral message to a requested hos- 
pital. The requested hospital sends the patient's information 
to the Registry Server and retrieves the CDA document after 
checking the registry information. Also referral reply and 
Information for Request are delivered as reverse way. Figure 
1 focuses on system architecture and technical approach of 
the MIES for medical information exchange process. 




Figure 1. Referral process from phy- 
sician's clinic to general 
hospital through medical 
information exchange sys- 
tem (MIES). CDA: clinical 
document architecture. 
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Figure 2. Medical information exchange system architecture. EMR: electronic medical record, CDA: clinical document architecture, 
EHR: electronic health record. 



The MIES was designed to exchange CDA documents be- 
tween designated medical facilities through the CDA Trans- 
fer Server with helping of Central Registry Server. The main 
function of this server is to manage the index information 
of patients subject to information exchange and facilitate the 
exchange of CDA documents via the CDA Transfer Server 
with this index information [5] . 

The MIES has two servers and needs to be connected to an 
adaptor. This adaptor plays a role of intermediary to trans- 
mit the CDA document and messages. The Registry Server 
stores the patient's information according to predefined 
schema and generates the index of patient, and it is used for 
searching CDA documents. Using the produced index of 
the patient, the CDA Transfer Server extracts the relevant 
CDA documents from the CDA Repository of the physicians 
clinic for transmission. Then, the transmitted data is stored 
at the repository of the requested hospital (Figure 2). 

The MIES is composed of three categories of services: The 
registry server manages information exchange and the reg- 
istration information of the CDA documents, and the CDA 
Transfer Server is used for the registration information, 



f Medical information exchange system 
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Figure 3. Service architecture of cal information exchange sys- 
tem (MIES). CDA: clinical document architecture. 



locates the proper CDA document from the relevant reposi- 
tory and transmits it [6] . The CDA viewer shows the CDA 
documents through connection with information systems of 
hospitals related (Figure 3). 

2. Application Methodology of CDA 

To share medical information between medical institutions, 
it is necessary to determine items to be exchanged. The items 
are defined in 'HL7 CDA' format which is the standard for 
XML-based CDA exchange. The used version is release 2 
version. 
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As a result, three templates can be generated: Referral 
Form, Referral Reply, and Information Release Request. In 
this study, lab test result, medication order and health sum- 
mary are summed up into an integrated template, and repro- 
duced into a standardized XML format. 

A CDA document basically consists of two parts: Header 
and Body [7]. The former contains patient's personal infor- 
mation and the latter contains medical information. 

In this study, the CDA Body was constructed in the Struc- 



tured Body type and was written out in the XML format. The 
Body encompassed items regarding lab test results, medica- 
tion orders and treatment summaries and was constructed 
in accordance with the CDA standard, as shown in Figure 4. 

We structuralized diagnosis, injection history, and test re- 
sults. In addition, we adopted 'entry' concept to achieve in- 
teroperability between different terms that have same mean- 
ings, so that the loss of information is reduced, and the value 
of information is raised [8]. More details are mentioned in 4. 



- <component> 
- <structuredBody> 
+ <component> 

- <component> 

- <section> 

<templateld root='2. 16.410.1. 11111.2.3* /> 

<code code="11348-0" displayName="Historv of Past Illness" codeSystem="2. 16. 840. 1.113883.6.1" codeSystemName="LOINC" /> 
<title>History of Past lllness</title> 

- <text> 

- <paragraph> 

<![CDATA[ - Reservation 2008-10-31 AM 10:00 ]]> 
</paragraph> 
</text> 
</section> 
</component> 

- <component> 

- <section> 

<templateld root="2. 16.410.1. 11111.2.3" /> 

<code code="29545-l" dlsplayName="Physical findings" codeSystem="2. 16. 840. 1.113883. 6.1" codeSystemName="LOINC" /> 
<title>Physical findings ; title > 

- <text> 

- <paragraph> 
- <i;CDATA[ 

#1. AR + AC , pale mucosa <o/3 SPT mice) 

SPT : Dp 2.2 Df 11 Tp 3 T5M 3 multiple mold Dog 
*2 . snoring T2A0 
*3. 3) Thyroid enlargement 
R/O Rt thyroid nodule 
R/0 Hyperthyroidism 
TFT : ISH 0.05 TG 124.3 
♦4. Excpthalmosis 
♦ 5. weight gam 10kg : increase 
f/u : thyroid sono & FNA 

]]> 

</ paragraphs 
</text> 
</section> 
</component> 

Figure 4. Clinical document extensible markup language (XML) format for diagnosis applying clinical document architecture (CDA) 
standard. 
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Application of Standard Terminology. 

3. Application Methodology of Data Transfer 

The Document Registry Framework (DRF) suggested by 
CIEHR of Korea is used to connect the Registry Server, which 
registers and manages information categories subject to ex- 
change, and the Repository, which stores and manages the 
CDA documents (Figure 5). 

A CDA document is stored at the Repository upon cre- 
ation, and registration information is stored at the Registry 
in the form of a message. To retrieve the generated CDA 
document, the Document Consumer obtains the CDA ID 
and information on the location of the Repository from the 
Registry, and finally gets the CDA document through ebX- 
ML. 

The DRF was provided in the format of Web service defini- 
tion language (WSDL) along with the API of a transmitting 



Implementation of MIES Based on EHR Standard 

module in order to be applied to various platforms easily. 
The system in this study was developed on ".NET" platform, 
and the API was applied by using the "Visual studio .net." 

4. Application of Standard Terminology 

Since a standardized terminology needs to be employed to 
transfer information of a diagnosis and medication from 
different systems, the code for the standardized terminol- 
ogy was adopted. The description of the standard code was 
made into CDA Entry level. To notate the diagnosis of a 
patient, ICD-10 codes were used and marked into the Entry 
in a CDA document. The medication was represented in the 
Entry level of CDA document by using the main ingredient 
electronic data interchange (EDI) codes. 
For diagnosis code ICD-10, the codeSystem sets 2.16.840.1. 
1 13883.6.3 at the Entry Observation (Figure 6). 



- <component> 
- <section> 

<templateld root="2.16.410.1.11111.2.2" /> 

<code code="29548-5" displayName="Diagonsis" codeSystem="2. 16. 840. 1.113883. 6.1" codeSystemName="LOINC" /> 
<title>Oesease Name( Diagnosis) < title > 

- <text> 

- <iist> 

- <item> 

<!'CDATA' Allergic rhinitis, persister.:, federate/ severe ]]> 
<^item> 
</list> 
</text> 

- <entry> 

- observation classCode="COND" moodCode="EVN"> 

<templateld root="2. 16. 410. 1.11111. 3.2" /> 

<code code="3303" displayName="Allergic rhinitis, persistent, moderate/severe" codeSystem="2.16.840.1.113883.6.3" 

codeSystemName="ICD 10" /> 
<statusCode code - completed" > 
<effectiveTime value="20061219" • > 

</observation> 
<^entry> 
+ <entry> 
</section> 
</component> 

Figure 6. Example of applying standard terminology to diagnosis. 



- consumable > 
- <manufacturedProduct> 

- <manufacturedLabeledDrug> 

<code codeSystem="2. 16.410. 1.10000. 4" codeSystemName="EDI Code" code="E018600Sl" displayName="Ensure Liquid' /> 

<code codeSystem="2. 16.410. 1.10000. 4" codeSystemName="EDI Cheif Integration' code="304700ALQ" displayName="Ensure Liquid' /> 

- <originalText> 

reference value="#ml" /> 
<''onginalText> 
<.'manufacturedLabeledDrug> 

- <manufacturerOrganization> 

•name >MEDI</name > 
<;/manufacturerOrganization> 
</manufac turedProduc t > 
^consumable > 



Figure 7. Example of applying standard terminology to medication. 
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The EDI code for medication is employed without alterna- 
tion and the codeSystem is set for 2.16.410.1.10000.4, along 
with the information on ingredients, dosages and manufac- 
turers of the drugs in use (Figure 7). 

5. Application of Security 

The security guidelines proposed by the CIEHR of Korea 
was used to ensure the information security. In this study, we 
aimed at building essential security systems for implementa- 
tion of online services, such as encryption in the communi- 
cation section, server security, and database security, protec- 
tion against hacking, contents and network security. 

For this purpose, the VPN was implemented to encode 
packet in each middleware section. To protect the database 
and the server, an encryption solution was applied. A web 
firewall was installed to protect hacking. Especially, to secure 
the data, all the transmitted data were sent out after encod- 
ing and decoded after receiving by using public-key cryptog- 
raphy. 

The communication through the Web Service mounted on 
the middleware is conducted by managing the certification 
codes for the middleware of each hospital so the access to 
the service is blocked if certification failed. 

When sending a message, each packet is encoded for trans- 
mission within VPN-controlled section. As the message 
calls the Web Service on the Registry Server; the paging 
call is verified against the Web Service Security Enhanced 
(WSE) for passage. Also, the Token in SOAP-type is checked 
for verification. Specifically, the ID and the password are 
checked. The password is encoded and stored in the database 
for verification. Finally, after certification, the encoded mes- 
sage is decoded and delivered to the final recipient. 

Furthermore, access control was accomplished by monitor- 
ing user's IP and Mac address on internal network in the 
security policy. 

III. Results 

1 . Registry Server 

The Registry Server stores meta-information for exchanging 
the patient's medical information to referral. It provides two 
types of services: messaging service which facilitates sending 
and receiving the meta-information, and the registry service 
which registers and manages information on exchange. 

1) Messaging service 

The messaging service is composed of the services of storing 
and inquiring the transmitted message. When transmitted, 
each message is made in the XML format. 
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The meta-information contains data of the sending and 
receiving medical institutions, medical staff in charge, res- 
ervations, diagnosis and meta ID. Especially, the meta ID is 
transmitted as a message produced by the OID rules. This 
OID is unique to each message, and serves as an index to 
search the relevant CDA document [9,10]. 

When receiving a message, it is delivered via the Web Ser- 
vice which known as the CDARegService. This web service 
uses the message decryption for decoding, and uses the mes- 
sage parser for interpretation, and stores the meta data to the 
database. 

2) Information exchange registry service 
For patient or hospital to subscribe this service, it needs to 
sign up for the service at the MIES Server for certification. 
The registration procedure is provided by Web Service at the 
EHR Registry Server. The procedure is tailored for the each 
stage of information exchange, and contains information on 
Referral, Reply, and Request. In addition, two other services 
are provided: one that verifies the consent to the release of 
the medical information, and the other that stores the regis- 
try information. The fields managed by Registry Server are 
shown in Table 1 . 

A certification message in a XML format is sent out, which 
activates the Registry Service from the MIES Server. The 



Table 1. Registry information type & description 



Field name 


Field description 


REG_HOS_ID 


Electronic health record agree institu- 




tion code 


REGJD 


Patient identifier 


REG_PT_NM 


Patient name 


REG_PT_SSNID 


Patient social number 


SND_HOS_CODE 


'Refer in hospital code 


SND_DEPT_CODE 


'Refer in hospital department code 


SND_DEPT_NM 


'Refer in hospital department name 


SND_DR_NM 


'Refer in doctor name 


RCV_HOS_CODE 


'Refer out' hospital code 


RCV _DEPT_CODE 


'Refer out' hospital department code 


RCV _DEPT_NM 


'Refer out' hospital department name 


RCV _DR_NM 


'Refer out' doctor name 


RSV_HOPE_DATE 


Reservation date 


METAJD 


Clinical document architecture docu- 




ment identifier 


DIAGNOSIS_CODE 


Diagnosis code 


DIAGNOSIS_NM 


Diagnosis name 
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final authentication undergoes the processes such as verifica- 
tion of consent, certification and EHR registration. The cer- 
tification message conveys the information on the ID code 
of the medical institution and the patient's social security 
number. These two pieces of information are used to check 
whether the EHR registration has been done or not. During 
transmission, the certification information is encrypted. 

When the consent information is absent, the Registry Web 
Service sends an "Authentication Fail" message to the origi- 
nal sender. Upon receiving it, the sender sends back the 
registry information. When the registry information arrives 
at the MIES Server, its Registry Service activates and regis- 
ters the information. Once the information on the patient 
and the hospital are registered, the Registry Service sends an 
"Authentication Success" message to the original sender, and 
the sender is now able to access the information exchange 
service and start the medical information exchange process. 

2. CDA Transfer Server 

When a hospital transfers patient to another institution, the 
requesting institutions send a referral message to the Reg- 
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istry Server and the CDA document is stored at the CDA 
Repository. To transmit the stored CDA document, the 
Transfer Server searches the CDA documents produced at 
the requesting institution or the receiving institution, and 
sends the relevant information to the requesting institutions. 

To search a document stored at the CDA Repository of the 
hospital, the unique index of the document is required to 
facilitate this process. Thus, a unique ID is assigned to each 
CDA document, and the unique ID is transferred as the 
meta ID upon message transmission. 

When requesting for transfer of a CDA document, the re- 
questing hospital sends to the requested hospital, the OID 
generated from the messaging Web Service. The link service, 
which searches the CDA record, is registered at the registry 
through the CDA Search Service, and the CDA Document is 
stored at the CDA Repository. 

The requested hospital finds out the location in the Registry 
in reference to the meta ID of the received message. Upon 
receipt of the request, the DRF Server searches the indexed 
document stored at the CDA Repository by the meta ID and 
transfers to the requested hospital. 
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Figure 8. Clinical document architecture (CDA) Viewer. 
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Table 2. Comparison of the prototype of the information exchange system and the MIES 



Subject 


Prototype of information exchange system 


MIES (System based on EHR standard) 


Subject institution 


Clinics, secondary hospitals (SNUBH) 


Clinics, secondary hospitals (SNUBH) 


No. of affiliated clinics 


9 


33 


No. of cases 


Appr. 1250 (2007.07.19 - 2008.6.20) 


Appr. 5100 (2008.06.21 - 2009.03.20) 


Information exchanged 


Diagnosis, medication orders, lab test result 


Diagnosis, medication orders, lab test result, surgery 
history, and medical images 


Documents exchanged 


Medical referral and reply form 


Lab, medication, health summary medical referral and 
reply form, request for release of medical information 


CDA level 


CDA R2 without entry 


CDA R2 with entry 


Standard terminology 


No applicable codes 


- Diagnosis: ICD-10 


- Medication: EDIcode 


- Item definition: LOINC 


Parties of exchange 


One-to-one exchange via gateway between 
hospitals 


One-to-many exchange via EHR registry server 


Transmission method 


Web service 


Web service (message) & ebXML (CDA) 


Encryption 


Secret key cryptography 


Public-key cryptography 


Platform 


.NET 


.NET & JAVA 


Security 


SSL, server vaccine, and firewall 


Encryption in the communication section, server 
security, database security, protection against web 
attacks, content security and network security, 
SSL implementation of VPN 



MIES: medical information exchange system, EHR: electronic health record, SNUBH: Seoul National University Bundang Hospital, 
CDA: clinical document architecture, SSL: secure socket layer, VPN: virtual private network. 



3. CDA Viewer 

When a hospital or a clinic refers or replies to another insti- 
tution, including medication information, LAB test results 
and the patient profiles the CDA document is generated. 

The requesting hospital needs a program to make the CDA 
document, CDA generator. Also, to see the CDA document, 
you need the CDA viewer which changes the CDA docu- 
ment into the document applied XML Style Sheet (XSLT) 
(Figure 8). 

IV. Discussion 

We developed a CDA standard-based medical information 
exchange system which electronically exchanges the medi- 
cal information items defined in accordance with the CDA 
document standard, adopting the standard transmission 
method and security devices. The security and standardiza- 
tion approaches covered all processes. 
To provide the better protection and security of the patient's 
information, the MIES established a Registry Server and a 



CDA Transfer Server separately in order to divide patient 
information and medical information. The Registry Server 
contains the patient profile and the indexes of the medical 
information only. Therefore it is possible to reduce the bur- 
den arising from management of the entire medical data. 
Each CDA document is maintained in the CDA Repository 
of each medical institution. 

The interaction between heterogeneous systems became 
possible by using middleware. Since MIES was constructed 
based on the exchange standard suggested by CIEHR of Ko- 
rea, any system can be accessed. 

Table 2 shows comparison of the old "Prototype of the 
Information Exchange System" and the new "MIES" devel- 
oped in this study. The "Prototype of Information Exchange 
System" was implemented to check possibility of medical 
information exchange between nearby several clinics and 
SNUBH. 

Currently, there's a lot of Hospital's demand to adopt this 
instant system for effective information exchange in Korea. 
To meet these demands, following study must be pursued to 
build an advanced system enabling information exchange 
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between multiple Hospitals and clinics. 

By applying international standards to exchange of infor- 
mation between different medical information systems, this 
study will expectedly contribute to medical information ex- 
change not only between domestic medical institutions, but 
also international medical institutions. 
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